AWS Lambda

Compressing image while uploading it to S3 bucket can be easily done using lambda. While if your workload require lot of execution time or there is large amount of data to be processed, also workload where tweaking environment to suit workload, lambda can be less appropriate. Instead other computer service like EC2 and elastic beanstalk can be well suited for such task.

-AWS Lambda can be used for cron job with AWS EventBridge.
-When we use AWS Lambda use with API Gateway to only transport data to another service without any business logic.

I would recommend using AWS Lambda when you have one-off tasks that can be accomplished with a single function and do not require a persistent, constantly running compute resource. Some example use cases include file or image processing, data analytics (you might have DynamoDB stream updates to AWS Lambda for processing), in conjunction with API Gateway as a backend.
I would not recommend using AWS Lambda when your Lambda function has potentially long-running, asynchronous calls involved (e.g., calling out to a service hosted in another cloud platform). This can drive up execution time and, in turn, cost. While Lambda layers allow you to share code between Lambda functions, I would not recommend AWS Lambda for cases where there are high degrees of interdependence between the Lambdas. I think that Lambdas work better when considered isolated.

[AWS Lambda] is very well suited for the projects that doesn't have any infra but needs it where short running processes are required. But if your application need to run continuously than this might not be the very apt tool for you.

I believe the main concern is about costs. If your function calls generates profit, no problem with the amount, as more [is] better. But if this is not the case and your user case trends to grow without associate profit, maybe by provisioning dedicated resources (EC2 instances for example) to run your functions will hurt less in your wallet.

Well suited:
1. when we need to worry about time to market and we don’t have infra defined.

Not suited:
1. Not suited for Business Client transactions as its server are located out of Switzerland and hence country laws are different

Working with Web and mobile apps well suited for Lambda. It provides a clear support path and improvement. Also it helps to reduce cost and accelerate speed of reaction on changes.

A sess appropriate scenario would be when CIO push to implement new technology and services without clear understanding of the results and project needs.

A great example of using AWS Lambda is when your application needs to be able to render images for the user and have those images be resized and optimized on load. Using AWS Lambda you can create endpoints with a minimal amount of code that allows your applications to request the images and use query parameters to declare the height and width etc.

AWS Lambda is most suited as a Serverless methodology. When you do not want to handle the software and only want to work on logic and code development, AWS Lambda is the best option. You can also trigger AWS Lambda from many AWS services like when a new row is added into DynamoDB or when a new file is uploaded to S3 or also when you want to execute Lambda once a day or at a specific intervals(cron jobs).

I would definitely recommend using Lambda for short-running, event-triggered processes that are dedicated to a single function. This could be for one-off processing or intermediate tasks between other resources like objects stored in buckets and queues for processing those objects. Also, since Lambda executions can be scheduled, processes that need to happen on regular intervals can be implemented with Lambda as well.
I would not recommend using Lambda for anything that needs to run longer than a few seconds. Long running processes like ETL jobs or intensive computations may be better suited for step functions, batch jobs, or even a server based approach.

The main area in my point of view is the automation reduction of costs. You can program and use Lambda to execute several tasks based in several types of events like logs, schedules, and output from other AWS tools. With the AWS API, you can do almost anything you want and your function will use only the needed resource (memory, cpu) so it is optimized.

AWS Lambda is very well suited to the scenario in which I use it; namely, Alexa skills. To respond to an Alexa skill request, it would be inefficient to spin up a server. For applications that run continuously and are not event-driven, AWS Lambda is not well-suited.

AWS Lambda is well suited for batch scripts, and API development.

AWS Lambda is well suited in cases where the entire stack is on AWS. It doesn't make sense to use lambda when you have services with other cloud providers.

AWS Lambda is best for short-lived applications/codes. Configure AWS Lambda to act based on the events that are produced on certain services. It works. We used it to move the RDS snapshot from WEST to EAST and EAST to WEST whenever the RDS automatic backups are done. It helps in other scenarios, like when application teams don't have a server or don't have a place to run a job on a regular basis. Then we can leverage this AWS Lambda to run the code against the database. As I mentioned, this is not suited for long-lived applications.

For its price, flexibility, and integration with other tools, AWS Lambda is the most popular serverless functions platform for a reason. In my opinion, it's best used as the backing behind some higher abstraction like Serverless or even Netlify Functions, but from what I've seen, it would be a great option even if used directly. In generall, serverless architecture works well for stateless applications, API aggregation, event-driven processes, and where the scale/demand is unpredictable.

If you're not afraid to get your hands dirty in wiring things up yourselves or you can use AWS' own abstractions like Amplify or SAM, then Lambdas and their surrounding platform pairings (Like SQS, API gateway) are great tools that can help you create a backend or infrastructure for a relatively low cost. If you don't find yourself in that camp, but you know your way around full-stack JavaScript frameworks and tooling, you may be better served with a higher level abstraction like what Zeit Now or Netlify offers.

AWS Lambda is best used in environments where you need to perform specific actions in response to an event happening. This reduces cost and will only be billed for the CPU time it takes to run the function. For long-running tasks, AWS Lambda is not good because of the timeouts set by the function.

Anywhere where you just pay for what you use. AWS Lambda is the best in those areas. As it is fast and scalable it can provide an excellent alternative for server backend making the whole application serverless. You just don't need the server running every time. Just run it when you need it.

AWS Lambda is great if you have a software design considering microservices with it. You can write an API with AWS Lambda and integrate it with API Gateway or you can integrate AWS Lambda consuming SQS or SNS events. You can even write an authorization lambda in front of your product.

AWS Lambda is suitable when we need to process data on demand and require a large number of instances. AWS Lambda is not too complex, and it will fit well in case we need an authentication function to verify user login information, process input data in S3, retrieve and execute message SQS or triggered on demand by the user. AWS Lambda would not fit if we needed to constantly receive user requests, run background processes or needed to access VM underline.

AWS Lambda allows us to develop certain process without setting up a server. I would recommend AWS Lambda for a process that doesn't need to be real-time or needs to be always on.

Product engineers can innovate rapidly as serverless architecture has alleviated the problems of system engineering. Thus, you spend less time on operational issues and it makes devops life easier.

It's good for a startup project because you do not need to spend too much money for the server and DevOps teams. With AWS Lambda, you do not need to worry about server managing, scaling, or managed infrastructure. It's free for 1 million requests per month, fewer developers are needed for the backend part, and it has fast deployment.

AWS Lambda is excellent for small organizations that want to focus on shipping features rather than maintaining infrastructure. Developers can iterate very rapidly using AWS Lambda, API Gateway, and the Serverless framework. AWS Lambda is not appropriate for some load patterns; services with uniformly high loads will be expensive to run on Lambda.